MODULE 1 CLOSURE
Spring 2010
Compiled by Greg Kinney

“MUDDIEST ITEMS”

QUESTION: 
My question has to do with the statement that the project manager is “responsible for outcomes while lacking full authority to command the requisite resources or personnel”.  I fail to follow this statement because it would seem to me that the project manager may have a difficult time commanding the requisite resources or personnel but they should have absolute full authority.  I could understand if the resources or personnel weren’t available due to financial reasons but if the project manager should have the authority to command resources or personnel that are available, right?
ANSWER:
One of the things we’ll cover in this class involves how organizations are configured.  Typically organizations are organized functionally.  For example, there is a sales department, an engineering department, etc.; then within the engineering department there may be a department for civil engineers, one for mechanical engineers, etc.  There are pros and cons to this form of organization – mostly cons in my opinion – but the fact is that this is a kind of organization that exists because most top level managers and executives are familiar with it.   This kind of organization does not breed cooperation and collaboration, and it’s difficult to get resources to play together well.   In the context of functional organizations, project managers really have a challenge getting adequate support from key resources in the parent organization.  Yes, they are held accountable for outcomes, but they’re often not given the resources to succeed. 
The situation for PMs is somewhat better with matrix organizations, which you will read about later.  The situation is best with projectized organizations, in which the PM is the boss and does command full authority over resources.  But projectized organizations are still somewhat rare.  And though they may streamline things for PMs, projectized organizations have their own set of problems.

QUESTION:
While I looked at the Chapter 1, I have a question about “routine work” and “quasi-project”. How could we clearly distinguish daily routine work and quasi-projects? In my daily work, it seems both of them mixed together. Should I utilize a project-management point of view to look at and deal with my daily quasi-project work?
ANSWER:
I can’t improve too much on the book’s description of routine work vs. quasi-projects.  Routine work happens daily.  Quasi-projects are often defined by looking into some unique request and performing the limited followthrough that is requested.  I believe a key distinction between quasi-projects and real projects is that for real projects there is a unique product or service provided.  For quasi-projects, you mount a unique effort but your outcome is typically some supporting step of some larger process, such as answering a question or defining something.

QUESTION:
Chapter 1 defines a program as a group of similar projects, yet often not distinguished from a project.  The distinguishing factor to me between a program and project is time.  In my experience, programs are ongoing through time…while projects have a definitive start and end.  Is this not an accurate way to think about these two terms? 
ANSWER:
The way that the authors present it is correct.   You are also correct that programs are normally executed over a period of time, but that is because there is a sequence of projects comprising a project.  For many reasons, you will not have the ability to execute all the projects at once; you might need to do one to make it possible to do the next, or you just don’t have the resources to do them all at once.

QUESTION:
On page 10 of the text, it mentions that one of the attributes of a project is uniqueness, in that though the desired end result may be achieved elsewhere, it is unique to the organization. To select an example from real life, my company recently had a project where we had to set up a full time operation on an oil field rig on the North Slope. The end result of the project was a full time operation, but it wasn’t unique in that there are two other rigs that have been set up similarly on the Slope. The task was set up as a project because the rig was a new rig and our company had never worked with the company that designed and operates the rig. So in this regard, how is it possible to state that uniqueness is an attribute of project management based on the description provided by the text? 
ANSWER:
Project uniqueness is variable.  The point is that your typical project is nonroutine; it’s not like flight operations that happen day in and day out.  In this case, the uniqueness may be with regard to the field formation, the design of the rig, etc.  But there may be elements that recur from one project to the next.

QUESTION:
My question is more from my personal experience, but I did not see it covered in the text. If a project team forms under the direction of higher management, is there any standard documentation that defines directs the project team? I have seen different proposals, contracts, memos, and charters. But it seems to differ between organizations. It there some industry accepted or PMI standard?
ANSWER:
The form of documentation will vary from one organization to the next.  PMI does speak to project chartering issues in PMBOK, but briefly, you will need to develop documentation that very specifically defines the deliverables of the project.  If you don’t, the project is very vulnerable to scope changes and to loss of focus as time goes on.  You will also need documentation defining roles and responsibilities.  Where external resources are involved, there must contractual definition of what is being delivered, when, and for how much. 
I don’t think that there is any one right or wrong format.  It is a matter of having chartering documents that are effective.